User talk:Drake178
Comparative Table of Normal Units I think you can work here. So history will be added to table page. --Wolfeek91 (talk) 21:17, February 1, 2017 (UTC) : That's an old habit I picked up elsewhere, I actually create the table through a text file anyway, I use the profile page to see the actual display quirks =D : I guess might as well go with your suggestion though. Drake178 (talk) 22:28, February 1, 2017 (UTC) Encounter Zones * Node colors and tile counts are determined previously. * Budgets are determined by one function, which then passes these to another to populate the lair, along with the coordinates including the plane. * The passed parameter (on the stack) for the budget is adjusted for difficulty (without saving the original value): :: Multiply by Difficulty + 1 (Intro is 0), then integer divide by 4. * Lair type: :: Straightforward value assignment for Nodes and Towers, Random(1-7) otherwise. * Lair color: :: Value assignment for Nodes. :: Random(1-6) for Towers, 2-in-6 black 1-in-6 everything else. :: Random(1-4) for b/w lairs, 3-in-4 black. :: Random(1-5) for colored lairs, falls through to be always green in 1.31. * Primary creatures: :: Set SelectedUnit to -1, HighestCost to 0 :: Repeat 200 times, or until SelectedUnit <> -1 ::: Roll divisor (1-4), store DividedBudget ::: Loop through units index 150 to 198 :::: If Race does not match lair Realm, next unit :::: If Transport is not 0, next unit (to exclude Floating Island) :::: If Cost <= HighestCost, next unit :::: If Cost >= (!!!) DividedBudget, next unit :::: Store Cost as HighestCost, index as SelectedUnit (only get here if there's a match) :::: Next unit :: If SelectedUnit is still -1 (after 200 divisor rerolls), the lair is empty, skip to treasure (budget). * Secondary creatures: :: Set SelectedUnit to -1, HighestCost to 0 :: Repeat 200 times, or until SelectedUnit <> -1 ::: Roll divisor (1-(10-PrimaryCount)), store DividedBudget ::: Loop through units index 150 to 198 :::: If Race does not match lair Realm, next unit :::: If Transport is not 0, next unit (to exclude Floating Island) :::: If Cost <= HighestCost, next unit :::: If Cost >= (!!!) DividedBudget, next unit :::: If index is the same as of the primary creature, next unit :::: Store Cost as HighestCost, index as SelectedUnit (only get here if there's a match) :::: Next unit :: If SelectedUnit is still -1 (after 200 divisor rerolls), there are no secondary creatures. * Treasure budget: :: Get PrimaryCount, multiply by PrimaryCost :: Get SecondaryCount, multiply by SecondaryCost, and divide by 2 :: Add the above two to get base treasure budget :: Adjust for difficulty, unless Impossible: multiply by 4 then integer divide by Difficulty + 1 (Intro is 0) :: Adjust for plane: ::: Multiply by Random(50-125) if Arcanus, Random(76-175) if Myrror, then integer divide by 100 :: If less than 50, set to 50 (otherwise no guardians = no treasure) * Treasure: :: If lair is Tower, add a spell: ::: Random(1-4) for rarity, square and multiply by 50 to get Spend value, reduce by 100, and deduct from TreasureBudget (if the spell is Common, this increases the budget by 50) :: Repeat until TreasureBudget < 50: ::: (Treasure rolls, I may exapnd this) :: If Special > 4, zero out all other treasure. * Return Drake178 (talk) 15:46, October 5, 2017 (UTC) : Thanks! I guess, it's the same algorithm for secondary creatures. If let's say 52 budget points are left for buying secondary creatures in a Death lair, then the lair should be always filled with secondary creatures (unless 200 random numbers turn out to be bigger than 2) and there should be a 50% chance to choose Zombies (divisor=1) and a 50% chance to choose Skeletons (divisor=2). : This part of what the OSG said seems to be also a little wrong, although it doesn't matter much: "If there are no such units, the game checks whether even the cheapest creature would fit into the undivided budget. If it does, it is selected as the primary guardian, otherwise the Encounter Zone will feature no defenders." If let's say 4 was chosen as a divisor the first time and the DividedBudget wasn't big enough to buy any monster type, then the algorithm will choose another random divisor the next time (the divisor could be 4 again, not the most effective kind of programming). For example, the next divisor could be 1 which is probably enough to buy a rather expensive unit (and not the cheapest). -- TumuRulez (talk) 19:12, October 5, 2017 (UTC) ::You're very much welcome, in fact I should be thanking you! =D ::Either way, no secondaries are still theoretically possible, however the chances are astronomically low. Same goes for no primaries if they don't fit the divided budget. "Astronomical" here starts at 1:1025. What is more surprising though is that creatures that match the divided budget indeed do not qualify. That will likely have an effect on some maximum treasure budgets that I assumed could simply be filled with price matching primaries. ::Listing minimum treasure budgets is pretty much meaningless in my opinion. I'm actually more inclined to come up with a way to get somewhat accurate average treasure values instead, but I'm not sure I can accomplish that. My current ideas are either too complicated or too inaccurate. ::Also, since you mentioned this, MAGIC.EXE has its own duplicate unit table, starting at dseg:$20C (sorry I don't have a direct file offset right now); this is what is used for generating monsters. Makes sense since the entire worldgen is in this executable, and this is why changing the values in WIZARDS.EXE doesn't work for this purpose. ::Drake178 (talk) 20:27, October 5, 2017 (UTC) : Muhaha, I stole a lucky edit from you (that's already my 4th, that's very much if you consider that 1/3 of the times I wasn't logged in when I posted over the years). Sadly, the tweaker doesn't seem to be capable to change those duplicated values in Magic.exe. :I wrote a Java program that calculates the theoretically achievable thresholds for treasure, depending on base budget, difficulty and realm (I also once wrote a program for the Starting Relation tables). Here is the code and here is the output for minimal treasure and maximal treasure. The columns are: budget (adjusted by difficulty), primary monster type x amount, secondary monster type x ammount, total monster costs (secondary costs are halved), maximal/minimal treasure (assuming 50%, 76%, 125%, 175% as multiplier depeding on Arcanus/Myrror and minimize/maximize). I assumed that those 200 rolls would roll each possible divisor at least once. I only used the upper and lower limits as budgets. Maybe values near the limits create more extreme treasure. E.g. I could imagine that a tower with 750 instead of 700 budget creates less valuable monsters or that a tower with 1150 instead of 1200 budget creatures more valuable treasure. I also can't guarantee its correctness; but it's late and I want to go to bed. -- TumuRulez (talk) 22:48, October 6, 2017 (UTC) ::I saw that steal. I mean... REALLY? Haha. Better you than the last guy if you remember that one too. =P ::Anyway, I love your idea of assuming that each divisor will be rolled at least once, and will likely go with that. I can use those values even if we don't want to check non min/max starting budgets. I'm not sure I'd want to list separate values for each color possibility though, but I'll think that through too. Either way, thanks for the table and the code =D ::Drake178 (talk) 10:51, October 7, 2017 (UTC) ::: "I'm not sure I'd want to list separate values for each color possibility though". I just treated each Realm seperately because it required less coding and putting realms together can be done easily manually. Of course the tables are way too big. Too many rows: I would only use rows for caves (Nature, maybe Chaos if 1.40), ruins (Death&Life put together), caves & ruins both in weak and normal as well in Myrror and Arcanus, all 3 Nodes but only under normal power setting (differing between Arcanus and Myrror), and Tower. Too many columns: that's a big issue but I would list the most extreme monster configurations if there's a way to put that information in a not-too-wide table. If monster configurations are listed, then I would go for 2 seperate tables, one for lowest treasure and the other one for highest treasure. I would only show the corresponding overland pictures for the monsters (no names) followed by their amount/number. Maybe, it's also possible to make 2 rows out of the information: one for monster types and amount, the other one for budget, combined monster costs, and min/max treasure. ::: I was thinking about how MoM creates the guardians and came to the conclusion that the algorithm is better than I thought. I just think that MoM should have used an additional divisor between 1 and 2 (e.g. divisor = 1.5) for both primary and secondary guardians and less divisors for secondary monsters (e.g. max divisor = 9 minus primary amount, max divisor is also limited to 4 if remaining budget is under 100). And the monster costs should have been more diverse for Sorcery and Death (e.g. see Night Walkers vs Werewolves). With those changes, there would have been more variety in monster type combinations. And I would have reduced the max divisor variable successively (originally max divisor is set to 4 for primary monsters): If a divisor fails to generate affordable monsters, then max divisor is reduced to divisor minus 1, and a value of 0 for max divisor would have been an exit condition (instead of 200 loops). Probably, the lair generation process only takes very little time of the world generation process, but it still bothers me. -- TumuRulez (talk) 13:21, October 7, 2017 (UTC) Terrain vs Node generation v1.01 code: * Bias variables :: Set SorceryBias, ChaosBias, and NatureBias to 0 :: For each sparkling tile do: ::: If ocean (/shore), increase SorceryBias by 1 ::: If Mountain or Desert, increase ChaosBias by 1 ::: If Grasslands or Forest, increase NatureBias by 1 * Determination code :: If ChaosBias > 0, create Chaos Node :: If Node tile is Ocean (/shore), create Sorcery Node :: Otherwise create Nature Node It could have been so much more... v1.1+ code: * Bias variables: same as above * Inserted 1.1 code, overwrites the bias variables: :: SorceryBias = Random(25) :: ChaosBias = Random(15) :: NatureBias = Random(15) * Determination code: :: If ChaosBias > SorceryBias and ChaosBias > NatureBias, create Chaos Node :: If SorceryBias > NatureBias, create Sorcery Node :: Otherwise create Nature Node And again... At the very least, the bias should have been added to the random rolls, either as a base or as a range extention. Hopefully, I missed or misinterpreted something, as Terrain has no effect on Node generation otherwise. I saw no code limiting the amount of sorcery nodes as described in the osg either, but that could still be elsewhere, I haven't even found the worldgen root function yet. Just going through some of the routines used to fill the various arrays. : -------------------- : Played a game in v1.01 and using Alt + RVL & Alt + PWR cheats, and it looks like you got it all right there. I also used the Tweaker in v1.31 to see what nodes got created (normal landmass). I checked 20 games, here are the results: : It's interesting that the distribution on Myrror is different, giving you much more SorceryNodes. Possible explanations: * a bigger influence zone can increase SorceryBias significantly * if there are too many SorceryNodes, maybe the game converts SorceryNodes into other Nodes, whereas that algorithm starts with nodes on Arcanus * There's a bug in the code looking for the terrain on the different plane when creating a node (like for WizardryTowers where the Myrror site is usually water). * Node creation process differs on Arcanus & Myrror : If you really mean SorceryBias > NatureBias & co and not SorceryBias >= NatureBias, then the chances should be as follows: * ChaosNode: 1015 / 5625 = 18% * NatureNode: 1240 / 5625 = 22% * SorceryNode = 3370 / 5625 = 60% : I am not saying that you are wrong. I just think there's a part of the algorithm you haven't discovered yet. From my experience what you have said (node type doesn't depend on neighbouring terrain) is true for Arcanus nodes placed in water, probably also true for the nodes on land (the terrain barely matters if it matters at all). Haven't played enough games on Myrror to say the same thing about Myrror. I think I will examine 20 further games on small and big landmass to see if there's a notable difference in percentages. -- TumuRulez (talk) 17:59, October 9, 2017 (UTC) ::There actually is a bug where Myrran Nodes don't have to be on land when they are created, Seravy wrote about this on RealmsBeyond and I can confirm it's there. It's the Arcanus tile that gets checked for being ocean rather than the Myrran tile (same coordinates). I assume this was already there in 1.01 too, creating tons of Myrran Sorcery nodes. For Sorcery vs Nature, the code jumps if SorceryBias <= NatureBias, I double checked that (but will triple that now =P). I also saw no other conditionals, like the one based on the original tile in 1.01. I'll try to look for other functions that write node terrain types to the map array. ::Drake178 (talk) 20:27, October 9, 2017 (UTC) ::: 20 games on large landmass (chose Jafar, normal difficulty, 1 opponent): ::: 20 games on small landmass: ::: There isn't that much difference in those tables. I could theoretically increase landmass further with the help of the tweaker. It's interesting that the number of blue nodes on Arcanus is not only smaller than on Myrror, the variance is also bigger. On Myrror, you see 5 to 8 sorcery nodes. On Arcanus it's 4 to 9 nodes. -- TumuRulez (talk) 22:33, October 9, 2017 (UTC) ::Found the limiter function, only have time for the short version now though. Guess what, the osg's 4 Sorcery Myrran limit is based on fact, they just misunderstood the way it works =D ::Anyway, Arcanus has max Sorcery limit of 9, converts to Chaos up to 6 first, then to Nature up to 6 (probably can't happen unless there were 0 to begin with?). Myrran has max Sorcery limit of 4, converts to Chaos up to 3 then Nature up to 3, so upper Sorcery limit is actually 8. Max converted amount is original amount less 9 on Arcanus and 4 on Myrror. ::Drake178 (talk) 23:28, October 9, 2017 (UTC) ::: So once, there are more than 9 sorcery nodes on Arcanus originally, the game will convert them into Chaos nodes until there are exactly 6 Chaos nodes? I don't understand completely what you said but the algorithm must convert multiple nodes at once or you would see 9 Sorcery Nodes on Arcanus way more often. I calculated the chances to get a certain amount of SorceryNodes before conversion (assuming 3370/5625 chance that a node becomes Sorcery) ::: So, the chances are roughly 52.3% to get more than 9 Sorcery Nodes on Arcanus (before conversion). And the chance are roughly 98.2% to get more than 4 Sorcery Nodes (before conversion). -- TumuRulez (talk) 07:02, October 10, 2017 (UTC) Here's the code for Node conversion, called separately for each Plane: * Count Nodes * Set ChaosConvert to 0, NatureConvert to 0 * Set ExcessSorcery to 0 * Arcanus branch: :: If SorceryCount > 9 then set ExcessSorcery to SorceryCount - 9 :: While ChaosCount < 6 and ExcessSorcery > 0 do: ::: Increase ChaosConvert, increase ChaosCount :: While NatureCount < 6 and ExcessSorcery > 0 do: ::: Increase NatureConvert, increase NatureCount * Myrror branch: :: If SorceryCount > 4 then set ExcessSorcery to SorceryCount - 4 :: While ChaosCount < 3 and ExcessSorcery > 0 do: ::: Increase ChaosConvert, increase ChaosCount :: While NatureCount < 3 and ExcessSorcery > 0 do: ::: Increase NatureConvert, increase NatureCount * Convert Nodes: :: While ChaosConvert > 0 convert random Sorcery Node to Chaos :: While NatureConvert > 0 convert random Sorcery Node to Nature * Return Drake178 (talk) 17:34, October 10, 2017 (UTC) :: Look at my numbers. I got 4 Sorcery Nodes on Arcanus roughly 40% of the time. When there were 4 Sorcery Nodes, it's been 6 Chaos Nodes and 6 Nature Nodes except for one time. I would say there's a bug in the code which let ExcessSorcery stay positive the whole time. In this case the algorithm would look as follows: If more than 9 Sorcery Nodes (if you got SorceryBias & co right, then it's roughly a 50% chance), increase Chaos & Nature both to 6. This would also match the numbers I got for 5 to 9 Sorcery Nodes. It's just that my numbers for 4 Sorcery Nodes are 10% too little. -- TumuRulez (talk) 19:33, October 10, 2017 (UTC) :::Oh, I was looking at the 9 Sorcery numbers wondering whats going on. Weird since I spotted the 3-3-8 Myrran setups right away. I'll check that, you're probably right! :::Drake178 (talk) 20:00, October 10, 2017 (UTC) :::There, fixed it. Clearly I'm imagining things =D -- Drake178 (talk) 20:22, October 10, 2017 (UTC) :::: So ExcessSorcery isn't mentioned once in the interior of the while loop? I wonder if this is a bug or not. If it is a bug, it's kinda helpful. 50% Sorcery Nodes on both Arcanus and Myrror would be too much. However in return, you get a big variance in number of Sorcery Nodes: Usually, it's either 4 Sorcery Nodes or 7 to 9 of them on Arcanus. I wonder why they used a higher SorceryBias in 1.1+ in the first place. Maybe just to test the node transformation. The node transformation in 1.0 was clearly made for small landmasses. -- TumuRulez (talk) 22:12, October 10, 2017 (UTC) :::My guess for the higher sorcery bias would be that they wanted ratios similar to what were produced by the previous code (erroneous or not). On smaller landmasses where nodes are mostly all close to oceans/shores that's probably what the original bias variables would have resulted in. Then again, I don't know whether the 1.0 code was different than the 1.01. It may have used more of those variables than just the chaos one. That being said, the 1.01 code would only have a 1:40 chance for a sorcery node on Arcanus i believe (that's the random chance of accepting a tile for node generation if it's an ocean tile, assuming its the same code as in 1.31, i never checked that). Myrror is obviously different because of the bug that checks the other plane for terrain, so it would be full of sorcery nodes in all versions. Maybe they tried and failed to figure out what went wrong there. :::As for the ExcessSorcery variable, you're correct, there's no sight of it inside the loops. On one hand, it's weird because it's not set up like a boolean variable. On the other hand though, converting up to 6 chaos nodes with above 9 sorcery would mean nature conversion only ever happens if there was 0 at the start, making that section fairly useless. It's possible they experimented with lower numbers and went with 6 in the end. Reducing above 9 directly to 4 doesn't strike me as a very good solution though. 5 may have worked out better resulting in 5-5-6's? :::Either way, I would have loved to see the bias variables actually used in a meaningful way, as the osg suggested, not just replaced with random numbers. -- Drake178 (talk) 21:53, October 11, 2017 (UTC) :::: I started about 10 games on v1.01 and had a look on the nodes on Aranus. I would say there are a bit over 1.5 Sorcery Nodes in average (normal landmass), sometimes no Sorcery Node at all (note I speak about Arcanus, there're plenty of them on Myrror). I also saw some Nature Nodes with Desert or Mountain in their zone of influence. If it was mountains, then this square always had a resource on top (diverse ores). Desert was more seldom. I could imagine that desert was originally not desert and got transformed to it because of illegal terrain or that the node failed to check all its sparkles (under circumstances desert only occured on Nodes with 10 sparkles, can't remember). -- TumuRulez (talk) 07:37, October 12, 2017 (UTC) :::I can't remember the landmass land tile percentages off the top of my head but 1.5 sounds around the right ballpark (probably closer to 1 than 2). If Normal is 30% for instance, 7 ocean tiles will be picked on average for every 3 valid tiles, so around 37 altogether by the time we get 16 nodes. Out of those, 1 in 40 will go through with creating the node, which will then be sorcery. Tiles picked for minerals do have a chance for being converted into a mountain, and i think that happens after the node array is filled, so that should indeed explain mountains around non-chaos nodes. I don't know about deserts though, afaik invalid tiles always transform into grassland. I did see some other functions altering terrain types that i didn't explore yet though, so it could also be somewhere there. -- Drake178 (talk) 15:41, October 12, 2017 (UTC) I've made tables regarding how many nodes are generated per realm. Would be nice if you could incorporate them in Node#Node_Generation. Those 4-6-6 and 8-3-3 occurences had a higher probability in my calculation than in those 30 test games I played. So not sure, if numbers are correct. The numbers are close to the real behaviour anyway. -- TumuRulez (talk) 18:18, December 12, 2017 (UTC) Arcanus: Myrror: :I most certainly will! It's brilliant, thanks for saving me that job (I'm likely much slower at it than you are) =D :It can pretty much go in as is (maybe a slightly smaller font size on the first and third tables), or we can put it into a template and transclude it (since it's not likely to need editing again). Drake178 (talk) 22:26, December 12, 2017 (UTC) ::Hmm, never mind the font size, it will likely either not fit anyway or not be readable. Might even go 100% with all of them (or just the same whatever that should be, I think that's more visually pleasing). I'll make note of the averages in the text instead, which I can also carry over into the individual articles. Drake178 (talk) 22:31, December 12, 2017 (UTC) ::: Thank you very much. Didn't realize those 2 tables had oversize. I measured the width of the tables in the Encounter Zone Article and got around ~835 pixels. However, sometimes 700 seems to be the limit. I think, it's best just to delete a few columns of tables 1 and 3. The chances to get 14+ nodes of the same type is always (far) below 0.00% there. -- TumuRulez (talk) 23:18, December 12, 2017 (UTC) Rampaging Monsters and Ruins While I'm still pretty far from uncovering this for certain, I accidentally stumbled on a function that seems to determine this. According to that, rampaging monsters have exactly 50% chance of creating ruins if, and only if, the town they take over is a fortress town (i.e. they banish or defeat a wizard by doing this). If anyone feels like testing (disproving most likely) this before I get around to it, be my guest =) -- Drake178 (talk) 23:49, October 13, 2017 (UTC) : I did some tests and I think it works like that: : - not fortress: There's a 50% that the monsters create a ruin and a 50% chance that the monsters disappear in the wilderness (probably doing some damage to the city first). : - fortress: The monsters always disappear in the wilderness. Fortress stays intact, wizard is never banished (even if no other town). :No matter the outcome, you seem to lose a percentual amount of your gold reserve. E.g. if the town makes 10% of the population of your empire, then you will lose 10% of your gold. If the monsters created a ruin, then you'll get all your gold back by clearing the ruin. -- TumuRulez (talk) 22:58, October 14, 2017 (UTC) ::So I probably read the conditional jump the other way around. Thanks! =D -- Drake178 (talk) 10:36, October 15, 2017 (UTC) This one : "v1.31 - v1.51 (WIZARDS.EXE) The first half of this is a funny blunder, the same variables are assigned regardless of which branch is taken, except in the opposite order... I.e. it's always the attacker's Realms being checked, even if the AI is defending. The second half is something you've already corrected pretty much everywhere else but here from what I see." Shouldn't there be 81D4D : 02->04 change as well? If I remember the order of realms correctly, it's 04 for Chaos, 10 for Death. With 02 it checks for Sorcery on Righteousness. Good catch btw I never noticed this bug...another fix that I can use in both 1.51 and CoM. SeravySensei (talk) 02:07, January 17, 2018 (UTC) :Damn, I'm being an idiot, I deleted that for some reason, I did originally write down all 5 of them. You're correct, of course! o.O Drake178 (talk) 03:16, January 17, 2018 (UTC)